Aminet 28

home *** CD-ROM | disk | FTP | other *** search

/ Aminet 28 / Aminet 28 (1998)(GTI - Schatztruhe)[!][Dec 1998].iso / Aminet / util / pack / PPatcher.lha / PP_v1.4 / Docs / PP.DOC < prev next >

Wrap

Text File | 1992-02-21 | 23.2 KB | 539 lines

¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ Powerpacker Patcher Version 1.4 Copyright (C) 1991, Michael Berg All Rights Reserved ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ INTRODUCTION Ever get tired of having to use PPMore or equivalent to view all those Powerpacked datafiles you have scattered everywhere? Or maybe PPMore doesn't do exactly what you want? Does your favourite ANIM player support Powerpacked anim-files? No? Well, this program should solve all your problems. It makes PowerPacker datafiles act completely as if they were normal files. In fact, with this program up and running, there is not one thing you can do with normal files, which you cannot do with Powerpacker datafiles. Regardless of what programs you are using. ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ RUNNING PP Powerpacker Patcher runs from either the Workbench or the CLI. If you use it from CLI, you need not RUN it, because it detaches itself from the current CLI process as soon as it is activated. If you run PP "as is", with no arguments, it will use RAM: for its background file decrunching. You may supply PP with one argument, describing the path it should use instead. You may designate any path (device or directory) you like, but keep in mind that PP will be writing and reading a lot in that path, so, if possible, use a fast device (RAM: or DH0:Temp/DecrunchDir). It is possible for you to specify PP's temporary path from the Workbench, too: Click (down, up) on PP's icon. Then press and hold either SHIFT button, and double-click (2*(down, up)) on the disk or drawer icon to be used for background file decrunching. PP will let you know if you made a mistake during startup. Since V1.3, PP has been told to be suspicious towards certain chances in the DOS. DOS is usually the primary target for link-vira, and with PP running it can be hard for a viruschecker to establish if a virus is active or not. So PP now does its own, very simple, virus checking. Read more about this in the virus section below. Besides the default path, you may give an option to PP, which tells it NOT to do the basic virus checking. The option may be given to PP either as a CLI argument like this: 1> PP DH0:Mydir/decrunchtmp -N or as a "Tooltypes" item in PP's icon, if you use PP from Workbench. The '-n' (Nocheck) is case insensitive and may appear anywhere on the command line. Further, another switch has been provided to activate the virus checking, even if this is actually the default. The switch for this is '-c' (Check). 'Tooltypes' switches look a little different: CLI argument Tooltypes equivalent -------------------------------------------- -c or -C CHECK -n or -N NOCHECK Switches are "permanent". Running PP again with another option won't work. Once Powerpacker Patcher has hooked itself into AmigaDOS, it will display a small banner message to show you that everything went all right. Powerpacker datafiles will begin to "act" as normal files as soon as PP has been activated. Most programs, commercial and PD, will be fooled into thinking that a powerpacked file isn't powerpacked at all. When they attempt to load such a file, PP will interfere and decrunch it before passing the file along to the calling program. ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ STOPPING PP Simple! Just re-run PP and the in-memory version will terminate immediately, if possible (see "caveats" below). DOS will be restored to its original state, and Powerpacker datafiles will again appear as ... Powerpacker datafiles! Note: PP silently ignores any arguments (CLI or Workbench) if another PP is already running in memory. ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ YOU'LL NEED... No, no ARP or anything like that. I just thought that I should mention that PP no longer needs 'powerpacker.library', like Pre-1.4 versions did. ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ MEMORY NOTICE If you use RAM: for background file decrunching then, to decrunch any powerpacked datafile, you'll need an amount of memory equivalent to what the file unpacks to, plus an additional 10k (112k for a file that unpacks to 102k). Older versions of PP would temporarily want more than twice this (one image in memory being written completely out to RAM: and then freed). PP V1.4 uses a highly intelligent "end-to-end fragment" allocation scheme that allows it to free the memory image WHILE the it is being written out to a file in RAM: To keep it simple: With PP 1.4 you can now load and decrunch much larger files than you could using older versions. Of course, all of this only applies when you use a memory-based device like RAM: for background file decrunching. For other types of media, it only means that PP returns the memory it needs (for decrunching) to the system faster than pre-1.4 versions. If PP can't find the memory it needs to unpack a file (or if its temporary path fills up), it will simply return the original (powerpacked) datafile to the calling program. This is potentially a bit dangerous, so in these low-memory situations, you may get some "READ ERROR" messages from whatever programs you are using. DON'T dispare - these messages have no other meaning than to tell you that memory is too low. Close some windows, terminate some programs, delete some files from RAM:, or anything else you can think of. If you get "READ ERROR" messages even if memory is NOT low, then it's time for you to conduct a lengthy session with your favourite disk-editor. Because then the message is for real. ;^) ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ SAMPLE APPLICATIONS Well, what is it all good for, then? Here's a small list just to get your juices flowing: o Viewing Powerpacker datafiles (text) Simply use the TYPE command - or bring the text directly into your favourite editor (Memacs, TxEd, CygnusEd, whatever) o Viewing Powerpacker datafiles (pictures) Load powerpacked IFF pictures directly into DPaint (or equivalent) o Icons Yes, that's right. Go ahead and crunch all those icons. Workbench will never know the difference. Remember to retain the names of the icons - DON'T use ".info.pp". Workbench recognizes icons as files with a postfix of ".info". o Include files (header files) Why not go ahead and crunch all your include files for your compiler? (believe me, it's worth it!) o Try to "LIST" a directory containing powerpacked files. Pick one out and remember the size of it. Now "LIST" that particular file. You will see that the size of your file has seemingly grown. Why? The first LIST gives you the actual size of the file. The second one gives you the size of the decrunced file... (this is really a side effect in PP, but quite useful in many situations) o Another side effect. To decrunch a file, simply COPY it from one location to another. The target file will be decrunched. o Much more There is no end to it. ANY kind of datafile may now be crunched, because it will retain its functionality 100% as long as PP is up and running. Script files for AmigaDOS, *.config files for programs that support config'ing, *.doc files for public domain disks, IFF pictures for DPaint, rexx scripts, makefiles, sound samples, printer drivers -- YOU NAME IT! ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ THEORY OF OPERATION It's okay to skip this section if you don't care for ugly programming details... It's simple, really. PP juggles with a few DOS library vectors, so that future calls to certain DOS functions are rerouted through PP. When a file-open request arrives, PP looks at the file in question in order to determine the filetype. If it is a special file (e.g. CON: or NIL:) a filehandle from the original DOS Open() function is returned. Otherwise, the file is decrunched to a memory block, which is then flushed into a temporary file on the RAM disk or in whatever directory you supplied PP with when you started it. A pointer to this new file is then returned. PP is, of course, intelligent enough to remove temporary files as these are no longer needed. Otherwise the temporary path would soon get crowded with squillions of useless files. If PP sees that the temporary file has been changed between the Open and the Close call, the file is rewritten over the original file, if possible. The result is, of course, NOT a crunched file. Future attempts to Examine() a powerpacked datafile will return the size of the decrunched file in the FileInfoBlock, and not the size of the Powerpacker datafile itself. Why? Imagine an editor trying to load a text file. It does an Examine() to get at the filesize. Then it allocates just enough memory to hold the file. It then loads the file into that memory area. Well, that just won't work if the filesize it receives from Examine() is about 50% too small. Keep in mind that as soon as an Open() attempt is made, the file is decrunched, and will thus have a completely different filesize! The above is also why some programs may report read errors in low-memory situations. Examine() has told them that the size of the file was, say, 100k, and yet they can read only 50k (if the crunch gain was 50%), which is the size of the crunched file. This is considered to be a read error by some programs. I have made PP as system friendly as possible with respect to memory requirements. The "end-to-end segment" allocation scheme allows PP to free parts of an allocated memory block, namely the parts it has already written to a file. This is achieved by first allocating the entire block of memory, and then, inside a Forbid()/Permit() pair freeing the memory again. The block is then reallocated (using AllocAbs()) in small, consequtive 10k chunks. This gives the caller a pointer to a memory block that he can free in equally sized chunks. I tried Nico's approach, which said that is was okay to do something like this: m = AllocMem(1000 bytes) FreeMem(m,first 16 bytes) m += 16 <use area from m to (m+1000-16)> FreeMem(m,1000-16 (the rest of the block)) But that will cause tremendous problems ("free twice" meditations) in low-memory situations. (Hope Nico is reading this, so he can fix his ppLoadData()! -Nico, read "fragalloc.c" and "myPPLoadData.c") For further details on the techniques involved, please read the sourcecode -- it's included for just that. You will probably notice that the program is all in one piece. I am profoundly against "handlers". This barbaric dissection of programs can make everything much more confusing and your L: directory a heck of a lot more crowded. Techies will argue, that the reason for splitting your code in a startup and a resident (the handler part) module is obvious; this way only relevant code stays in memory and the startup code terminates at once. Well, the startup code part is rarely much more than a few K (often much less), and I myself gladly sacrifice that small an amount of memory, if this means that I don't have to copy two files for every executable I have. Handler code is only for *exceptional* programs, where NO OTHER solution seems acceptable. ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ CAVEATS Yep, there are a few of these, too. First of all, you have to remember that PP is a one way street. This means that loading Powerpacker files will work fine, but trying to save them again will result in a non-crunched file. The powerpacker.library sorely lacks a crunch function. (Note: At this point, I'm not considering Nico's new Powerpacker V4.0b library) Secondly, when working with crunched icons (or, for that matter, any other type of crunched file), there is a nominal performance reduction caused by the decruncher. Don't expect crunched icons to pop up at the same rate as they used to, or crunched include-files to get included as fast as they used to. In pre-1.4 versions of PP, this effect could be quite annoying - especially for diskette based, highly fragmented files. V1.4 & later, however, use a much more efficient algorithm. Use of B.A.D. and Addbuffers is still highly recommended, though. Thirdly, when you want PP to terminate, you may get a funny message back, saying that it isn't possible to stop the in-memory PP right now. When you get this message, it is because some other program is currently using internal procedures in PP. Wait until all disk activity has been completed, and then try again. If some faulty program "crashed" before it could close all its files, or if it simply forgot to close them, you may not be able to remove PP at all. Further, if you are using other programs that patches the same DOS vectors as PP, you have to terminate these before PP can be terminated. If, for example, you have started PP and then SnoopDOS, you must terminate SnoopDOS before PP can be removed. PP will work happily with any machine configuration I can think of. It has been tested on an A500 using AmigaDOS 1.2, with .5Mb extra RAM fitted, but has also works happily with AmigaDOS 2.0. Further, it has been tested with programs such as "FragIt", "SnoopDOS", "VirusX" and "VirusChecker". I don't have a MMU, so no Enforcer checks have been made (and I don't think that it is even possible to test PP with Enforcer). ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ PP AND VIRUSCHECKERS You do have a viruschecker, right? Well, when you are using PP, it is quite possible that your viruskiller will report that a virus has found its way into memory. Don't be alarmed, this is quite normal. PP works because of library patching, and does in fact look a lot like a virus. PP hogs these four vectors: LVOOpen, LVOClose, LVOExamine, LVOWrite Right now I can't really think of any approach to make PP transparent to viruscheckers. But if at any time PP sees that someone has changed any of the above four vectors, it gets suspicious and displays a small message in a console window. This message only appears once, even if one of the vectors are changed yet again after that point. This behaviour is optional and can be turned off with the NOCHECK/-n flag. If PP says that your machine is under attack by a link-virus, don't you believe it. 99% of the time it is simply a harmless program that needs to patch the same vectors as PP. But, unless you know EXACTLY what is going on, you should rely more on a virus checker than on your own judgement. A link-virus is a very nasty and higly intelligent creature, and it WILL outsmart you in most cases. So be careful. PP is not much of a virus checker, agreed, but it does provide the basics. Future releases may possibly contain much more powerful virus protection mechanisms, so rest easy. Get in touch if you have suggestions on this. ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ KNOWN BUGS Erm.. none, as far as I can tell. However, don't try to remove PP's temporary directory while it is still running. If you do, PP will not work any longer (it won't crash your system, though, but it will act just like it does in low-memory situations -- see "READ ERROR" comment above). In pre-1.4 versions, the autodetaching was sloppy. If run from a script (such as your startup-sequence), the EndCli command would refuse to close the CLI window. Moreover, any messages printed by PP would appear after the CLI prompt, and that's just plain ugly. However, 1.4 and later fixes these problems. And now for the funny parts. There is a very strange bug lurking around somewhere in the Workbench. To test this, try the following (you'll need at least one external drive, or a hard drive): o Load Workbench o Start PP o Insert disks in DF0: and DF1: o Start any program from DF1: and keep it running. (Doesn't really matter what program it is, as long as it runs for some time) o Eject the disk in DF1: (Step 4 was to prevent WB from removing the DF1: icon when you remove the disk) o Click ONCE on DF0:'s icon o Press and hold either SHIFT button o Double-click on DF1:'s icon BANG! Workbench crashes (GOMF: "Code likely out of control") and summons the dreaded Guru dude. I discovered this peculiarity by accident, and immediately thought that PP was at fault. After hours of fruitless bug hunting, I decided to run SnoopDOS while performing the procedure outlined above once again. Without PP running, of course. And guess what. Workbench crashed once again. This can only be because of two things: Either, There's a bug in Workbench or There is the same bug in PP and in SnoopDOS There are pros and cons for both of these. If you try the procedure without anything funny running in the background (no PP or SnoopDOS or anything like that), Workbench doesn't crash, and does what you expect it to do. However, the chance that exactly the same bug should exist in two programs (by two different authors) is very slim. And SnoopDOS is considered to be a textbook example of a well-behaved program (PP doesn't do too bad, either ;^) Further, Workbench 2.0 does not exhibit this behaviour, so it is probably the 1.2/1.3 Workbench who's at fault. For now, I'm going to let the problem rest. It IS a borderline case, agreed, but it could potentially cause problems in other situations and other programs. My best guess is that WB is making assumptions about scratch register contents after certain DOS calls. This is a no-no, as you well know. If you have any idea what the heck is going on, don't hesitate to mail me (see address below). ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ UNKNOWN BUGS...? I've had reports from people who can't get PP to cooperate with ARexx properly. rexxarplib.library's getfile() has been reported to guru when PP is installed. If you have Professional Page you may also run into some trouble. It is hard for me to fix these kinds of problems, because it may not always be PP who is at fault. Further, I don't even have the software involved (ARexx, ProfPage, etc), so when these "inexplainable" gurus occur, just don't use PP for that particular purpose. At least not until I can find a way to fix things. During version changes, it is quite possible that I "accidently" fix some of the problems, so whenever you receive a new version of PP, try it out with your software again. You never know... 8^) ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ REMAKING PP I've enclosed a makefile suitable for Matt Dillons "DMake". Just CD to PP's home directory, and say "DMake". That's really all there is to it. Oh, by the way, remember to set CCOPTS to nothing before issuing the DMake command (the DMakeFile handles parameters for CC on its own). PP will then be remade using large code, large data & 32 bit integers. Large code & data, because other processes will be executing internal procedures in PP, which is virtually impossible using the small memory model. ( Sure it's possible, but I'm lazy! |^) ) ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ THANKS GO TO... Well, who other than Nico François. Nico's powerpacker.library, and, for that matter, all the other powerpacker tools, are simply brilliant. Credit where credit is due! ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ FUTURE RELEASES Version 1.0 of PP was pretty much a beta release, and 1.1 didn't support all you 2.0 guys & girls. This version (1.4), however, should be free of nasty surprises. There's still a multitude of possibilities for improving PP. Some obvious choises: ¤ More control on PP. Switching PP temporarily on and off while it is running. Possibly through hotkey combinations. ¤ Option to specify multiple paths for file decrunching, such that if one fills up, the next will be used. ¤ Maybe build in a screen blanking facility or PopCLI style hotkeys for starting a new CLI. Will this be useful, or will it merely interfere with the real PopCLI? Let me know. ¤ Improving the virus protection mechanisms ¤ Patching more DOS functions. DeleteFile() is a good one. This would enable to the user to verify the "dangerous" actions of a new program (a small autorequester: "ARE YOU SURE (blabla)"). ¤ More on this: Turning PP into a simple virus protector as well. ¤ Integrating PPLoadSeg and PP, as suggested by Arthur Pÿpers (I am opposed to this proposition, however) ¤ Anything else that YOU would find useful! The overall effect of this program is quite astonishing. I use it all the time. Try it - it is just fantastic to see how *.pp files act as if they were completely normal files! ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ SHAREWARE PP is shareware. As you know, this means that I would like a little something if you use it frequently. Something like $5+ (emphasis on the PLUS) will get you the latest two updates of PP, as soon as these are ready (more money probably means faster development...). Please read the file 'Shareware.ANGER' included in the distribution... ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ FLAMES If you find anything you (dis)like, mail me. You're gonna have to write to me actually using old-fashioned ink and paper, because I'm not yet in the modem business. If you can't remember how to hold a pen, get one of the tribe elders to show it to you. Anyway, here's my address: Michael Berg Sct. Peders Gade 24A, 2th 8900 Randers DENMARK (I expect to purchase a modem shortly, so be prepared for some real havoc on all those BBS's 8^) ) Have fun! Oh, by the way. I'm no good at drawing icons, and as you may already have seen, the icon for PP looks quite terrible. But how do you represent a program such as PP in a graphical manner? Please feel free to contribute any suggestions for what the icon for PP should look like. If I see something I like (data or merely ideas), I may even use it with future releases of PP. ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ __ /// __ /// \\X// AMIGA - There Can Be Only One ¯¯¯ ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨